Mobile wireless networks are becoming more and more important and the sizes of the mobile networks tend to increase. Such mobile networks are particularly mobile ad hoc networks, and for example they may operate in groups which are independent and contain for example up to hundreds of nodes. With an increasing network size the nodes may be spread out in areas which are larger than the actual radio coverage of the individual nodes. Routing techniques then have to be implemented to make it possible for such nodes which are out of range to communicate with each other via intermediate nodes. Generally, to provide for appropriate routing in such mobile ad hoc networks using a routing protocol is different from, and much more complex than in wired networks with static nodes. Two important factors to take into account are that the mobile ad hoc networks normally have a limited bandwidth and high rate of topological changes. Therefore routing protocols are needed which aim at minimizing the control traffic at the same time as rapidly adapting to link failures and additions caused by node movements. Due to the fact that mobile ad hoc networks tend to grow in size, there are problems with scaling up. Classical protocols such as routing Internet protocol (RIP) and routing shortest path first (OSPF) are not convenient e.g. due to the fact that they generate far too much control traffic and they are only capable of accepting a few topology changes per minute.
Two kinds of routing protocols have been suggested, namely reactive protocol and proactive protocols.
Reactive protocols do not need to exchange control data in the absence of data traffic. The route discovery procedure is invoked on demand when a source has a new connection pending toward a new destination. The route discovery procedure normally consists of flooding a query packet and the return of the route by the destination. The amount of flooding can be very extensive and hence expensive and also create delays in route establishment. Additionally, route discovery via flooding does not guarantee any optimal route in terms of hop distance.
Proactive protocols, such as optimized link state routing (OLSR), need periodic updates with control packets and therefore generate additional traffic which adds to the actual data traffic. The control traffic is then broadcast throughout the network via optimized flooding which is possible since nodes permanently monitor network topology. OLSR uses multipoint relay flooding which significantly reduces the cost of such broadcasts. OLSR, for example described in “Optimized Link State Routing Protocol”, RFC (Request For Comment) 3626 by T. Close and P. Jaquette et.al, October 2003. OLSR inherits the concept of the link state algorithm, for example “OSPF version 2, ” IETF Request For Comments 2328, April 1998 by J. MOY, and uses shortest path first forwarding. It exchanges topology information with other nodes of the network periodically and every node maintains the topology information for the whole network. The routes are computed based on such topology information held by the nodes. Since it is proactive, as discussed above, routing is available immediately when needed.
However, OLSR implements a concept of forwarding and relaying from HIPERLAN (a MAC layer protocol, Medium Access Control, as standardized by ETSI, for example ETSI STC-RES 10 Committee, Radio Equipment and Systems: High Performance Radio Local Area Network (HIPERLAN) Type 1, functional specifications, June 1996. It uses MPR, cf. for example “Performance of Multipoint Relaying in ad hoc mobile routing protocols”, Networking 2002, Pise, Italy 2002 by P. Jacket, A. Laouiti, P. Minet, L. Viennot, to optimize flooding. Each node selects a set of its neighbour nodes as its MPRs. In OLSR only MPR nodes are responsible for forwarding control traffic intended for diffusion into the entire network, which has a consequence that the number of transmissions required is reduced. Nodes selected as MPRs by some neighbour node or nodes, announce such “MPR selector” information periodically in their control messages. This means that a node announces its reachability to the nodes having selected it as an MPR. The reachability information is used to calculate routes from a given node to any destination in the network. This is more thoroughly described in IETF RFC 3626. OLSR in principle is a routing protocol based on a cross-layer design and it collects link state information and uses it to calculate routes and make optimization. However, since it collects link level information with IP layer HELLO packets, the layers are not crossed in implementation.
In order to improve OLSR, QOLSR as described in “Quality of Service for ad hoc Optimized Link State Routing protocol (QOLSR)”, has being suggested by Hakim Bades, Khaldoun Agha, Draft-Badis-Manet-QOLSR-Ol.txt, April 2005. QOLSR provides optimal QOS routing functionalities in terms of available bandwidth and delay and it also uses MPR to minimize control traffic. QOLSR only requires partial link state and corresponding QoS information to be flooded in order to provide optimal routes under QoS constraints as those in the whole network topology. All nodes selected as MPRs must declare the link QoS information to their MPR selectors using TC (Topology Control) messages. QOLSR improves OLSR in that in neighbour sensing, each node estimates the QoS conditions (available bandwidth, delay, loss probability, cost, security, power consumption etc.) on links to each neighbour having a direct and symmetric link. The TC messages are extended in that QoS conditions of the links between the node and its MPR selectors are added into the data structure. The routing table is built from such a database using a loop-free shortest widest path algorithm to find a path with maximum bandwidth using a variant of Dijkstra routing algorithm. If there is more than one widest path, the one with the shortest path delay is chosen.
In another modification or extension of OLSR, a service discovery mechanism suggested. A new message type is then defined to handle the functionality of service discovery, service location extension (SLE). Service queries and responses are forwarded implementing the forwarding mechanism of MPR. SLE is used to automatically discover architecture and locate servers.
However, all suggested modifications or extensions of OLSR, are based on creation of private message types and design of private tables in order to support new services, cf. SLE as discussed above. A similar approach is adapted by a so called plug-in design in OLSR. The OLSR plug-in provides access to the necessary functionality in the OLSR daemon. The user can add new functions to OLSR by linking a plug-in into the daemon without changing OLSR daemon code. However, in order to guarantee the stability of the OLSR daemon, the internal tables are read-only tables which are private and private message types are created. Although such designs are flexible for individual plug-in developers and the daemon is kept stable, these improvements are provided at the cost of increased complexity and configuration and increased control overhead in terms of number of control messages.
Moreover, for implementation of OLSR plug-ins, the OLSR daemon has to add two timers for each plug-in or service, one for state time out and the other for message generation. Each timer has its own timer interval. For example, for an OLSR daemon with 5-10 plug-ins, this means that the configuration and the maintenance will be complex. As furthermore each plug-in implements private messages, the control overhead will be considerably increased which may produce congestion, particularly in networks with scarce network resources.